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[57] ABSTRACT 

A communication network and process for communicating 
thereon is disclosed which can support multimedia commu- 
nications. Communication channels are formulated using a 
two step process. In a first step, channel types and fixed 
attributes thereof are defined. When needed, one or more 
channels of the predefined types are subsequently allocated 
in a second step wherein user-definable parameters are 
specified. The user-definable parameters and fixed attributes 
of each allocated channel control the scheduling of trans- 
mission and receipt of information on each channel. 

10 Claims, 6 Drawing Sheets 
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FIG. 5 

(PRIOR ART) 



TCP OUTPUT 



BUFFERS CON- 
TROLLED BY 
SEMAPHORES 




PORTS FOR 
SEGMENTS SENT 
TO TCP 



QUEUES FOR 
PACKETS SENT 
TO IP 



25 



I/O 


25 ~X 


I/O 




I/O 


PORT 




PORT 


• • « 


PORT 



operating system 
hardware"""" 

-25 



02/29/2004, EAST Version: 1.4.1 



U.S. Patent Dec. 16, 1997 Sheet 5 of 6 



5,699,361 



FIG. 6 




02/29/2004, EAST Version: 1.4.1 



U.S. Patent Dec 16, 1997 Sheet 6 of 6 5,699,361 




02/29/2004, EAST Version: 1.4.1 



5,699,361 

1 2 

MULTIMEDIA CHANNEL FORMULATION more I/O ports 25, a main memory 27, a disk memory 29 and 

MECHANISM an audioMdeo VO device 31. The bus 21 is for transferring 

data between the devices 23-41 connected thereto. The main 
memory 27 and disk memory 29 are far staring data. The 

FIELD OF THE INVENTION 5 processor 23 is for executing instructions for purposes of 

The present invention relates to communications net- processing data stored in the main memory 27 and disk 

works. In particular, the present invention relates to a memory 29 or received or outputted via the audio/video I/O 

strategy for providing cornmunications channels in a net- device 31 or the I/O ports 25. 

work for supporting multimedia communications, i.e., a Each I/O part 25 is connected to a network 10 or 11 for 

combination of text, audio, video, control, etc communica- io purposes of providing communication thereon to and from 

tions. the host 14. Each VO port 25 is capable of receiving the 

_ „ ^ ^ packets transmitted on the respective network destined to the 

BACKGROUND OF THE INVENTION * ogt u ^ wMdl ^ m port ^ „ containe i Each I/O port 

FIG. 1 depicts a communication network 10. 25 is also capable of transmitting packets originating at the 

Illustratively, the communications network 10 is Fiber Dis- l5 host 14 in which the I/O port 25 is contained on the network 

tributed Data Interface (FDDI) network although the corn- 10 to other destinations. Such packets may be temporarily 

munications network 10 could also be an Ethernet network, stored in the main memory 27 or disk memory 29. 

Token Ring network, Asynchronous Transfer Mode (ATM) The audio/video I/O device 31 illustratively includes a 

network, etc display device such as a cathode ray tube (CRT) or liquid 

The communications network 10 includes a communica- 20 crystal display (LCD) for displaying still and moving 

tions medium 12 for carrying information between host pictures, and loudspeakers for reproducing audio signals, 

computers or nodes 14. The communications medium 12 Illustratively, the audio video VO device 31 also includes a 

may include optical fibers, coaxial cables, unshielded microphone, for receiving voice input, a camera for receiv- 

twisted pairs of wires, switches, multiplexers, etc. ing video input, and a keyboard and mouse for receiving text 

Illustratively, communications is achieved by transmitting a 2s and other data/control input 

bitstream over the communication medium 12 which bit- Illustratively, the hosts 14 communicate according to the 

stream is organized into packets or cells. The invention is Transfer Control Protocol (TCPyinternet Protocol (IP) or 

illustrated herein with a bitstream that is organized into User Data Protocol UDP/IP. These protocols control, 

packets. FIG. 2 depicts an illustrative packet 40 which amongst other things, the packetizing of information to be 

includes a header portion 42 for carrying control information 30 transmitted, the reassembly of received packets into the 

and a payload portion 44 for carrying data. The header originally transmitted information, and the scheduling of 

portion 42 illustratively includes an address of the destina- transmission and reception of packets. FIG. 4 illustrates a 

tion of the packet This address may be a datagram address transmission scheme according to these protocols. See D. 

(unique identifier assigned to the host which is to receive the COMMER, INTERNETWORKING WITH TCP/IP, vol. 1 

packet) or a virtual address (identifier which is aynamically 35 (1991); D. COMMER & D. STEVENS, INTERNET- 

assigned to each communication). The hosts 14 transmit WORKING WITH TCP/IP, vol 2 (1991). Illustratively, 

packets on the cornmunications medium 12. The hosts 14 sucn schemes are implemented by suitable software 

also monitor the cornmunications medium 12 for packets executed by the processor 23. According to UDP, an appli- 

transmitted thereon from other hosts 14. In response to a cation program executed by the processor 23 divides data for 

specific host 14 detecting a packet destined thereto (i.e., with 40 transmission to another destination into segments of variable 

an address corresponding thereto), the host receives the length. The application program then generates descriptors 

packet for further processing. Otherwise, the host 14 ignores for each segment, called segment descriptors, and submits 

or discards the packet transmitted on the communications such descriptors in requests for transmitting the segments. A 

Tn F ^ 111 Tn ^* UDP process (not shown; contemporaneously executed by 

The commu nication s network 10 may be a stand-alone 45 the processor 23) enqueues the segment descriptors in the 

network or may be interconnected to other networks to form queue 60. In the case of TCP/IP, an application program 

a larger network. For instance, FIG. 3 shows the commu- simply generates a descriptor for each buffer, called a buffer 

nications network 10 connected to a bridge bl. The bridge descriptor, which indicates the storage location of data to be 

bl serves to isolate the communication network 10 from transmitted. The application program then submits such 

other networks, such as the communications network 11, yet 50 buffer descriptors in requests to transmit the data in the 

enable communications between the two networks 10, 11. buffers. (Herein, "buffer" refers to a portion of the main 

Collectively, the bridge bl, and communications networks memory 27 or disk memory 29 in which data is temporarily 

10 and 11 farm a local area network or LAN il. The LAN stored.) A TCP process 56 (contemporaneously executed by 

LI may be connected to a router r2 via the bridge bl. The the processor 23) enqueues each buffer descriptor in a queue 

router r2 serves to route communications received thereat to 55 50. A TCP timer process 52 (contemporaneously executed 

the LANs attached thereto. Illustratively, the router r2 and by the processor 23) periodically generates control descrip- 

other routers r3, r4 are interconnected via a backbone tors which are also enqueued in the queue 50. TheTCP timer 

network B to form a campus or enterprise network C (so process 52 also transmits messages to the TCP process 56 

called because such a network is typically deployed at an which, in response thereto, dequeues the control message 

individual enterprise or campus of office buildings). The go and buffer descriptors from the queue 50, in a first-in 

campus network C is connected to a wide area network first-out order. The TCP process 56 performs different time 

(WAN), such as the Internet, via a router rl. The WAN sensitive management in response to the control messages 

sprawls from campus network to campus network enabling such as ensuring mat packets are successfully received at 

communications between a host at one campus network and their destinations within a threshold period of time after 

one or more hosts at one or more other campus networks. 65 transmission. (According to the TCP protocol, a first host 

As shown in FIG. 1, each host 14 includes a bus 2L which receives a message packet from a second host trans- 

Connected to the bus 21 are, a processor or CPU 23, one or mits a special control packet back to the second host 
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acknowledging receipt of the packet. The TCP process 56 mit and receive communication paths require enqueuing a 

executing at the second host waits a certain threshold period descriptor, relating to the transmitted or received data, into 

of time after transmitting the message packet to the first host at least two queues (60, 70) (70*, 80') or (70', 50'). Second, 

for receipt of the acknowledgment control packet If the the number of queues 70, 70' provided for transmitting or 

second host does not receive the acknowledgment control 5 receiving packets which are directly accessible by the I/O 

packet within the threshold period of time, the TCP process ports 25 equals the number of VO ports 25. Stated another 

56 executing at the second host assumes that the message waVj mere is a one _to-one correspondence between the 

packet was not successfully received and retransmits the queueg 70 and 70* and the VO ports 25. Therefore, the 

message packet to the first host.) TheTCP process 56 divides transmission of packets for each cornrnuiucation, and the 

the data in the buffers into segments and generates a segment 10 reassembly of received packets, is also controlled by the 

descriptor for each segment TheTCPprocess thenenqueues strict ^t^ut ordering of the queues 70, 70\ The 

each segment descriptor in the queue 60. The TCP process transmission and receipt schemes of FIGS. 4 and 5 are 

56 may also enqueue other segment descriptors in response therefore said to be non-preemptive because the transmis- 

to die control descriptors (e.g., segment descriptors of data slon and reaS sembly ordering cannot be changed to give 

to be retransmitted) into the queue 60. 15 certain communications priority over other communica- 

An IP process 62 (contemporaneously executed by the tions. 

procestor 23) dequeues each segment descriptor one at a q k desirablc t0 multime<lia communication* on 

time, in afirst-in tat-out order from the queue 60. The IP networks ^ as & nctwork 10 . Multimedia communica- 

fT? i!!^? t / Gr <^ h ,e "J»? descriptor tioM communications ^ combinarions of 

Including appropriate header inf onuaUon and ™ «he data M ^ gtffl ^ yQi(x ^ ^ ^ text/transactional 

ofthese^nuntothepayloadportonof ^epacketThelP communicatiOD ^ control ^ m intcractive ^ 

process 62 then enqueues each packet into the one of foe non4nteractive fashions . ^ of communications 

nansmisswn queues 70 associate with a selected i/u port haye mmnt characteristic8 . Textfransactional communi- 

qU TJ?K S aSS ^ < ^ W ^l COire t !Kr^ g ca«ion ^ *«*y; communication exhibits a high aver- 
VO port 25 from _wroch the packet is to be transmitted. The 25 age to peak bandwidth ratio. Video and audio communica- 
ble i Jn JT 1 ^™ 00 * c tions are stream-oriented; they require a rather continuous 
destination^ mer^d^Thatis, meffprc«ss«2in^uns bandwIdm mC have ^ average bandwidth which fe typi- 

•^(t^aM^ to^toMro cally much higher than that of the text/transactional com- 
port 25 to ^transmit packets m order to ^ver toem to the munlcatlolls . ^ ^ ^ mi audlo must ^ outputted to 
e^esponding destination host ad .I/O port .25 dequeues 30 the u a continuous fashion without detectable 
the packets from the corresponding transrmsaon queue 70, ^ substantia]ly video and audio 
in a nrst-m &st-out order andfransroits the packet on the communlcatloils . At ^ ^ gaps ^ merely a^o^g , 0 
communicatioBs network 10 attached to that specific I/O m e U5 er; at worn, mc gaps can rento the rer^duwd audio 
P°_„ ' _ ... ... . or video unintelligible to the user. Furthermore, interactive 

na 5 lUustrates a receiving scheme according to the 35 communicationS) especially interactive audio 
TCP/IP and UDP protocols. Each VO port 25 is provided communications, require that there be little latency between 
with a receipt queue 70'. Each I/O port 25 receives packets aA of me communication. Otherwise, the par- 
from the communications network to which it is attached, ticipants on each end must pause for long periods of time to 
and enqueues ttje received packets in its corresponding tecelw a response to i^on^on transmitted to the partici- 
recemt queue70 . The IP process 62 periodically retrieves 40 p3S1 on me othcr end. Such pauses are unnatural for inter- 
each packet from each of the receipt queues 70" in a nrst-in communication substantially degrade the corn- 
fir st-oot order (e.g., the receipt queues 7C may be accessed munication. 

in a round-robin fashion). The IP process 62 then reas- _ j .t™»™ _ , . . . - . 

sembles the segments from the packets by extracting the The TCP/ff andUDP/ff prcwcols are designed for bursty 

data in the paytoad sections of the packets and storing the « n on " in f actlve ' transactional onente4 communications, 

segments. Ifthe received packet was a UDP packet, the IP U 3ueh c ° mmumcatl0ns - 15 neifl f a «°? tu,ul ^ 

aocMS «2 aeneratesi a ^semaaBtdescriDtorfbr wch se^rt requirement nor a maximum latency ceiling. Rather, all 

sLts^ts^ !L iXI^L. ;„ JL,^. „™„, information is transmitted or received in a roughly compa- 

^Tk* w ™r%2J ^ Zr rable flrst-in flxs t out fashion. It is possible to use TOMP 

%ZLJ?t%£?% *f imp and UDP/TP to deliver multimedia information in a comma- 

descriptor into one of the UDP receive queues oO . The 50 , ^ ^_ . . . » 

. f^T,.. „ . . - Q . - fiM *_^ t i ^^f^^ f « ni cations network such as the FDDI communications net- 

lntormation is dequeuea in a nrst-in nrst-out oracr rrom the . <A „ « ^ ^. ^. 

«mn ^ *u 1- ^ . . , . work 10. However, because there is no differentiation in 

UDP queues to the application program which is to receive * , 7 UTTiff * « a uv umaouLl f uw " m 

the segment If the received packet was a TCP packet the D? treatment amongst the different lands of communications 

proceT62 enqueues the segrnent descriptor into a TCP (no yam ^^ ^M can only enable a limited 

receive queue 5<T. The segment descriptors are dequeued 55 amoun 0 a c. 

from the TCP receive queue in a first-in first-out order by the ^ is therefore an object of the present invention to 
TCP process 56 which assembles the segments into the overcome the disadvantages of the prior art 
originally transmitted data for each communication. This nT _ „, ATW ^„ TOm ^ T 
datHs stored in a buffer corresponding to a specific com- SUMMARY OF THE INVEOTION 
munication. The TCP process 56 also signals an appropriate go This and other objects are achieved according to the 
semaphore to indicate that a buffer of data is available for an present invention. The present invention illustratively 
application program to retrieve. In response to a signaled employs a host computer of a network similar to the con- 
semaphore, an application program can receive the data in ventional communications network. Communication is 
the respective buffer when convenient for that application. achieved by transmitting a bitstream on one or more corn- 
Certain observations can be made regarding the above- 65 munications media in the form of packets or cells. Each host 
noted transmission and receipt schemes. First, a multi- computer includes one or mare VO ports which connect the 
layered queue structure is employed wherein both the trans- host computer to the communications medium of one or 
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mare communications networks. The I/O ports are con- enabling transmission of data on specified channels, the 

nected to a processor and a memory via a bus. Each VO port streamer process dequeues descriptors from the transmit 

receives packets or cells destined to the host and transmits queues of the specified channels and transfers the packets 

packets or cells from the host computer on the respective corresponding to the dequeued descriptors for transmission 

connected communications media. 5 from specific I/O ports. In response to control messages 

According to the present invention, three processes are enabling receipt of data on specified channels, the streamer 
contemporaneously executed by the processor of the host to process dequeues descriptors from the receive queues of the 
provide communications at the host A formulation process specified receive channels and reassembles the data of the 
is provided for defining different types of communications packets corresponding to the dequeued descriptors, 
channels and for allocating channels of the predefined types. 10 ^ channel type definition step of the formulation pro- 
A real-time scheduler process receives requests from an cesg eDable5 a 3y Stem ^ to predefine different channel 
application process, contemporaneously executing on the ^ ^ of which is suited for canying packe ts 0 f a 
host, for allocating channels. In response, the real-time respcctivc typ C of communication, i.e., interactive 
scheduler process determines if adequate resources are communications, streamed data, control data, reliable data, 
available to support the additional requested communication 15 ctc . On me other hand, me dynaniic alloc^on step enables 
channels. If so, the real-time scheduler process causes the ^ user OT applicatioiI to create a multimedia session with 
formulation process to allocate the channel. Furthermore, different combinations of communication types with differ- 
the real-time scheduler schedules each allocated channel for cnt quantities ^ quaUties tbmtiL ^ user is pro _ 
communication in response to a timer by transmitting con- me ^st of both worlds; a variety of predefined 
trolmessagesmdicatmgonwMchcr^ 20 channcl types are provided for different kinds of 
receipt should occur. A streamer process is also provided communica tions, which the user may structure and vary in 
which responos to the control messages outputted from the onJer to a multime<iia session of me use rs choice, 
real-time scheduler. The streaming process packetizes appli- 
cation data for transmission and selects packets from alio- BRIEF DESCRIPTION OF THE DRAWING 
cated channels (which channels are specified by the control 25 . . 
messages) for transmission from an appropriate I/O port HG - 1 shows a conventional communications network. 
The streamer process also reassembles received packets of FIG. 2 shows a conventional packet 
allocated channels (which channels are specified by the FIG. 3 shows the interconnection of the network of FIG. 
control messages) into the originally transmitted data for 1 into a large communications network, 
receipt by an application. 30 pi G 4 jflustrates a conventional packet transmit scheme 

According to one embodiment a two step formulation according to TCP and UDP. 

process is provided. Imtially, one or more channel types are HG s mustratcs a flOTto||1 tet schcmc 

defined and fixed attributes are assigned to each channel according to TCP and UDP 

type. Illustratively, this is done by the system designer and rrrr ^ "~. 1f . ' J( A . „ A , 

is not changed in normal use. Thereafter, applications submit 35 *K3. 6 illustrates a host according to an embodiment of 

request to allocate channels of only the defined types as me P" 8 * 1 * invention. 

needed. In allocating a channel, the application specifies FIG. 7 illustrates the inter-relationship of processes for 

user-definable parameters for the channel. The formulation communication according to an embodiment of the {resent 

process allocates the requested channels. Illustratively, the invention. 

fonnulation process also generates a receive queue for each 40 DETAILED DESCRIPTION OF THE 

channel allocated for receipt and a transmit queue for each INVENTON 
channel allocated for transmission. These queues are main- 

tained by the streamer process for ordering the transmission FIG. 6 illustrates a host 100 according to the present 

and receipt of data on a channel by channel basis. invention. The host 100 has an internal bus 112. A processor 

Illustratively, channels are only allocated by the formu- 45 114 is provided for executing application programs and 

lation process after a determination is made by the real time processes as described below for achieving communica- 

scheduler that the host has adequate resources (i.e., buffers, tions, A main memory 116 and a disk memory 118 are 

bandwidth on the communications network, etc.) to support provided for storing instructions for execution by the pro- 

the additional channel, in addition to any channels already cesser 114 and data, such as packets of information for 

allocated. Once allocated, the real-time scheduler process, 50 transmission from, and receipt at, the host 100. One or more 

consults the user-defined parameters and fixed attributes of I/O ports 122 are also provided which are attached to one or 

each channel in determining when to schedule the transmis- mare communications networks via a respective communi- 

sion and receipt of data on each channel For instance, the cations medium The VO ports 122 are far transmitting 

user definable parameters can specify the number of buffers packets from the host 100 in the form of a bitstream. The I/O 

to allocate to the communication, a bandwidth requirement, 55 ports 122 are also for receiving packets, in the form of a 

a quality of service, a direction (transmit or receive), etc. bitstream, destined to the host 100 which bitstreams propa- 

Such information controls how often and in what priority the gate on the respective attached communications media. An 

real time scheduler signals the streamer process to transmit audio/video VO device 124 is provided which illustratively 

packets for each channel. Applications submit data for comprises a display device, such as a CRT or LCD, an audio 

transmission on specified channels to the streamer process 60 reproduction device, such as loudspeakers, and audio 

which segments and packetizes the data for transmission. source, such as a microphone, a video source, such as a 

Hie streamer process generates a descriptor for each packet camera, and a manual text input device, such as a keyboard 
and enqueues the descriptor into the transmit queue assigned and mouse. The bus 112 enables the transfer of process 

to that specific channel Likewise, the streamer process instructions and data (including packets) between each of 

receives packets from the I/O ports and enqueues a descrip- 65 the devices 114-124. 

tor for each received packet into the receive queue assigned According to the invention, communication is achieved 

to that specific channel. In response to the control messages using three processes, called the formulation process 310, 
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the real-time scheduler process 320 and the streamer process 
330, which are contemporaneously executed by the proces- 
sor 114. The inter-relationship of these processes is Illus- 
trated in FIG. 7. 

Prior to discussing the processes, the data types utilized 
by the processes arc first discussed The communication 
process illustratively uses the following data types: data- 
gram descriptors, data unit descriptors, channel type table 
312, allocated channels table 314, receipt queues 336 and 
transmission queues 334. Each data structure is illustratively 
stored in the memories 116 and 118. Each of these data types 
is briefly described below. 
Datagram Descriptors: 

A datagram descriptor is generated by the streamer pro- 
cess 330 for each packet to be transmitted. Datagram 
descriptors for packets to be transmitted are destroyed by the 
streamer process 330 when the corresponding packet is 
transferred to an I/O port 122 for transmission. Datagram 
descriptors are also generated by the streamer process 330 
for each packet received from an I/O port 122. Such data- 
gram descriptors for received packets are destroyed by the 
streamer process 330 when the packet is reassembled into 
segments. A datagram descriptor has the following fields: 



Allocated Channels Table 314: 

The allocated channels table 314 stores an entry for each 
allocated channel. Entries are generated by the formulation 
process 310 in response to the real-time scheduler process 
320 detennining that there are sufficient resources to support 
a requested channel. Hie entries are likewise destroyed by 
the formulation mechanism 310 when the channels are 
deallocated by the applications. Each entry of the allocated 
channel table 314 has the following fields: 



10 



is 



20 



rhann^l Tn 

channeL_type 
parameter 1, 
parameter^... 
paramcterJ 



attributel, 
attribute?;... 
, attribute/ 



a unique cumber assigned to each allocated 
channel 

the channel type of the aiWatffH channel 
user-definable parameters which may be 
specified by the application when requesting 
the channel, for example, buffer size, 
bandwidth requirement, quality of service, 
header information, channel direction (transmit 
or receive), etc. 

different fixed attributes associate with the 
channeL_type in the channel type table. 



datagram— ID a unique value identifying the specific 

datagram descriptor 
pointer a pointer to the mem o ry loca t ion in the packet 

buffer 332 at which the corresponding packet 

is stored 

size the size of the packet 

offset the position of the corresponding packets 

payload data relative to the beginning of the 
segment from which the packet payload data 
was formed 



25 



30 



When an application submits a request to the real-time 
scheduler process 320 to allocate a channel, the application 
specifies a value for the J parameters (where J is an integer 
>0). (Alternatively, for those parameters not specified, 
default parameters are assigned.) The allocated channel 
table entries are accessed by the real-time scheduler process 
320 in determining when to signal the streamer process 330 
to transmit packets of each channel. 
Receipt Queues 336: 

One receipt queue 336-(N+l), 336-(N+2), . . . , 336-(M) 
is generated and assigned to each of the M-N allocated 
receive channels by the formulation process 310 upon 
allocation (where M and N are integers such that M£N£0). 
Likewise, the formulation process 310 destroys each receipt 
queue 336-(N+l), 336-(N+2), . . . , 336-M upon deallocating 
the corresponding channel The size of each allocated receipt 
queue 336-(N+l), . . . , 336-M is illustratively set by the 
formulation process 310 according to a 4t buffers" parameter 



pomtw 



rlafn tmi^ jt fr^ 



a pointer to the memory location in the 
receive buffer 338 at which the canesponding 
segment is stored 
the size of the segment 



Data Unit Descriptors: 

A data unit descriptor is generated by the streamer process 35 
330 fox each data segment reassembled from one or more 
packets received from an I/O port 122. Each data unit 
descriptor is destroyed by the streamer process 330 as a 
result of normal garbage collection (i.e., after an internal 

timer indicates that the segment corresponding thereto has 40 in the allocated channels table 314 entry for the respective 
gone stale). A data unit descriptor has the following fields: channel. Each queue entry includes a datagram descriptor 

and a link to the previous queue entry. The receipt queues 
336 are accessed by the streamer process 330 which 
enqueues data unit descriptors for each packet received by 
45 the I/O ports 122 into the receive queue 336-(N+l), 336- 
(N+2), . . . , 336-M associated with the channel of the 
received packet. The streamer process 330 furthermore 
dequeues data unit descriptors from the receive queues 
336-(N+l), 336-(N+2), . . . , 336-M, of specified channels, 
50 in a first-in first-out order in reassembling the transmitted 
data from the received packets. 
Transmission Queues 334: 

One transmission queue 334-1334-2, . . . , 334-N is 
generated and assigned to each allocated transmit channel by 
55 the formulation process 310 upon allocation. likewise, the 
formulation process 310 destroys each transmission queue 
334-1,334-2, . . . , 334-N upon deallocating the correspond- 
ing channel. The size of each allocated transmission queue 
334-1, , . . , 334-N is illustratively set by the formulation 
The formulation process 310 generates each channel type 60 process 310 according to a "buffers" parameter in the 



Channel Type Table 312: 

The channel type table 312 is initially generated by the 
formulation process 310. The channel type table 312 has one 
table entry corresponding to each channel type with the 
following fields: 



type 

attribute 1, 
attribute^... 
, attribute/ 



an identifier of the rhamwl type 
different fixed attributes which are preset 
initially and are not user-definable, such as 
access mode. 



table entry initially. The channel type table 312 typically is 
not changed thereafter. Each entry corresponds to a defined 
channel type which may be later allocated. Only those 
channel types predefined in the channel type table 312 may 
be allocated. Each channel type is assigned I (where I is an 
integer>0) fixed attributes which cannot be altered by the 
applications which request allocation of channels. 



65 



allocated channels table 314 entry for the respective channel 
The streamer process 330 forms packets from data received 
from applications and enqueues datagram descriptors of the 
packets into the transmit queues 334-1334-2, . . . , 334-N of 
the channels corresponding to the packets. The streamer 
process 330 dequeues descriptors from the transmission 
queues 334-1334-2, . . . , 334-N, of specified channels, in a 
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first-in first-out order in response to control messages from 
the real-time scheduler process 320. 

The formulation process 310, real-time scheduler process 
320 and streamer process 330 are briefly discussed below. 
Formulation process 310: 

The formulation process 310 is used to define communi- 
cation channels. The process is a two-step process. Initially, 
channel types are predefined, such as interactive media, 
control, continuous media, reliable data, etc, Once defined, 
these channel types are generally not changed in normal 
operation. Thereafter, an application executed by the pro- 
cessor 114 of the host 100, submits requests (as described 
below) for allocating communications channels of the pre- 
defined types. The formulation process 310 allocates the 
channels of the predefined types. As illustrated in FIG. 7, N 
channels 1, 2, . . . , N are allocated for transmission and M-N 
channels N+l, N+2, . . . , M are allocated for receipt where 
N and M are integers. 

The following pseudo code outlines the operation of the 
formulation process 310. Illustratively two subprocesses are 
provided: 



Defining Channels in Channel Type Table 



define channel^type_table data structure to include a variable 

number of channci_typc_tablc_cntrics; 
input channel_typc_couDt; 

allocate channel_type_jtabk[l..chaiineLj&pe_countJ of type 

channcL_typc__tablc data structure; 
for n = 1 to chartne l_type_ccmnt 

obtain inputted specification fix 11 th channel type from user 

including xnput_cbacneL_type and 

mput^chaTinrl_attribiitsl T ..., h^uLjchainKL_attributel; 
channeL_table[n].type := input_jchaimeL_type; 
channcLJablefn] .attribute 1 input_charmcL_attributc 1 ; 

chara»L_tabk[n] .attributel := inpuL_chaimeLattribute 1 ; 
} 

Allocation and Deallocation of Channels 



allocate channcl__table(l. maT_rhannrU3 to include mai^_ghannelg 

somber of cbannel__table__cntrics ; 
aloe ate charmel__tabel[l] for. connection-less trasmit 

communication Get up control channel CO 

{ 

chaiinel_jable{l]£haimel w JD := CO; 
ohamy l__Tab lc( 1 j .chairaeLjype := CTRL; 
(±anDeL_teblc{l].parameterl p= 
comm_jet_.up_ctrL_parl; 

channel_table[ l]-parameterJ-:=: 

comm__£et-up -Ctrl parJ ; 
all oca te a transmit queue for CO; 

} 

allocate channel table [ 2] for connection-less receive 

communication set up control channel CI 
{ 

channeL_table[l]xiianndLJD CI; 
channel tablet lj-cfaanneLrype ;= CTRL; 
channeL^able(l].parimeterl := 
mmm set up i ctr L par 1 ; 

channcljablc[ 1] .parameterJ := 

coram sct-up-ctrl par J; 
allocate a receive queue for C I; 

} 

nexL-ch next available channel_table entry; 
loop while formulation process still executing 
{ 

if a request to allocate a channel is received from the real- 
time wberinler process with inrpi t^harine1_TD t 
iDput_channeL_type, inpuL-parl,..., inpuL_parJ 
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{ 

assign default parameter values to iion-6pecified 
input_parj; 

5 allocate channcL_tablc[ncxt__ch] 

{ 

chan»Ltabte[ncxt^ch]jhftnneL-ir> := 

inpti t^fibflf^LTri ; 
channeL_table[next_ch]xhaimeL„type := 

input, channel—type; 
10 channel_table[next_ch].paraineterl := 

inpuL-parl; 

channcl_tablc[ncacU.ch].parameteiJ ?= 
mput_parj; 

} 

~ if the channel to be allocated is a transmit channel 

then 

allocate a transmit queue for the channel having 
a size equal to the buffers parameter of 
chamxl_Jabk[rjext__ch] ; 

else 

allocate a receive queue for the having 
20 a size equal to me buffers parameter of 

channel_tab le[next_ch] ; 
next_jch := next available chance L_table entry; 

} 

if a request to deallocate channel having channrLTD = = 
inputs channeI_JD is received from the real-time 
25 scheduler process 

{ 

search channel_rahle for channel_Jable[ptr] for which 
channeL-tablo [ptr] channe LJD = = 

input _ cha^n«|_ TT) ; 

delete channel_table{ptr]; 
30 h? the channel to be deallocated is a transmit channel 

deallocate the transmit queue for the channel 
else 

deallocate the receive queue for the channel; 
next_.ch next available chacneL-table entry; 

35 , } 



Real-Time Scheduler process 320: 

The real-tune scheduler process 320 receives the requests 

40 to allocate channels generated by the applications and deter- 
mines if there are sufficient resources to satisfy the requested 
channels. If so, the real-time scheduler process 320 causes 
the formulation process 310 to allocate those channels for 
which there are sufficient resources, The real-time scheduler 

45 process 320 also regulates the transmission of packets on 
each channel in response to a timer process 340 and accord- 
ing to user-definable channel parameters and fixed channel 
attributes as described in greater detail below* 
Below is pseudo code of five illustrative subprocesses 

50 executed by the processor 114 in executing the real-time 
scheduler process: 



Chancel Allocation 

if a request Rl is received from an application to allocate one or 
more channels where Rl includes one or more specified 
parameters mpux_parl v ..^npiiUparJ for each requested 
channel then 

if there are msnffriml resources such as space in the 
channoLjable, bandwidth, buffers, etc., to accept Rl 
then issue a rejection message to the application 

else 

{ 

call streamer process with message Ml for 
transmission on ffciTin*! CO to remote host 
specified in Rl, which message Ml indicates 
caapliinentary channels for Rl to be allocated 
at the specified remote host; 
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{ 



for each requested channel 



{ 



generate unique cbaooeLJD; 
call formulation process to allocate a 
chanael_table entry with 
nrp^t_4wl r . n input_j«rJ and 

rharmftl TT) ; 

allocate resources such as bandwidth, 
buffers, etc.; 

} 

return channeLJDs to application; 

> 

else 
{ 

if returned message M2 from CI is 
M2 = = REJECT then issue a rejection 
message to the application; 

CompltTTM-titary ChairnH Allocation 

if a message Ml is received on CI requesting allocation of 
complimentary channels for a request R2 issued from a 
remote host then 

if there are insufficient resources such as space in the 
chaimeLjable, bandwidth, buffers, etc., to accept R2 
men call streamer process with message M2 « « 
REJECT for transmission on channel CO to the 
remote host that transmitted message Ml; 

else 



{ 



for each requested channel 

{ 

generate unique rtnnmH„ Tp; 

call formulation process to allocate a 

channeLjable entry with 

input_parl T ...,input__parJ and 

chanr»L_TD; 
allocate resources such as bandwidth, buffers, 

etc.; 

} 

return channeLJDs to application specified in message 
Ml; 

call streamer process with message M2 = = ACCEPT 
for transmission on channel CO to the remote 
host that transmitted the message Ml; 

1 

Channel Deallocation 



if a request R3 is received from an application to deallocate a 

rharmrj with the f hannrl TH =: = input chartnH TH thffll 

if inpuL_channeLJD does not exist in channeLjable then 

issue rejection to application which issued R3 
else 
{ 

call formulation process with request to deallocate 
input_c.hannr.l_TD from channet_Uble; 

call streamer process with message M3 for 
transmission on rhannftl CO to remote host 
and application with which the application 
mat Issued R3 is communicating, wherein M3 
indicates the "~plt— * tn f — y channel at tfie 
remote host which should be deleted; 

deallocate resources inch as bandwidth, buffers, etc.; 

issue completion, message to application which issued 
R3; 

} 

CompUmcnrary Channel Deallocation 

if a message M3 is received via channel CI from a remote host 
requesting the deallocation of a complimentary channel for 
a channel having channeLJID = ~ mrM_ch anncj ED then 



{ 



call formulation process with request to deallocate 

input channel rn from channel table; 

deallocate resources such as bandwidth, buffers, etc.; 
issue channel close message to locally executing 
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wait for returned message M2 on channel CI; 

if returned message M2 from CI is M2 = = ACCEPT, 



} 



application that is commumcating with the 
application executing on the remote host 
specified in M3; 



10 



15 



20 



Regulation of Transmission and Receipt on Channels 

receive timer activation message from timer process; 
Loop while bandwidth quota is not met for mis time slice; 
{ 

access channel—table to determine next channel to be 
serviced based on bandwidth requirement of channel 
and available bandwidth for this time slice; 

determine the amount of data to be transmitted or received 
for this channel based on the bandwidth requirement 
of the channel and the bandwidth quota available for 
this time slice; 

if next channel to be serviced is a transmit channel then 
call streamer process with ^'hann^i m of next 
channel and value specifying the number of packets 
to be transmitted; 

if next channel to be serviced is a receive channel then 
call streamer process with crwrmeL.Tr> of next 
channel and value specifying the cumber of received 
packets to be reassembled into segments for receipt 
by the corresponding application; 

} 



25 Streamer process 330: 

The streamer process 330 receives data to be transmitted 
from the host 100 on the communications network. The 
streamer process 330 packetizes the data to be transmitted. 

30 The streamer process also receives packets from the com- 
munication network via the I/O ports 122. The streamer 
process 330 reassembles the data from the received packets 
and transfers the reassembled data to the respective appli- 
cations. Both the packetizing of outgoing data to be 

35 transmitted, and the reassembly of incoming data from 
received packets, are described in greater detail below. The 
streamer process 330 receives control messages from the 
real-time scheduler process 320 which regulate the trans- 
mission of packets of each channel. In response to the 

40 control messages, the streamer process 330 transfers packets 
of specified channels to an appropriate I/O port for trans- 
mission on the communications medium attached thereto. 
The streamer process 330 also receives control messages 
which regulate the reassembly of data from incoming pack- 

45 ets received from the J/0 ports 122. 

The following is pseudo code for five subprocesses 
executed by the processor 114 in executing the streamer 
process 330: 



50 



55 



60 



Transmit Packets of a Channel 

if a request to transmit a specific number of packets for a specified 
channel is received from the streamer process then 



{ 

dequeue one datagram descriptor from the bead of the 

transmit queue associated with the specified channel 

for each packet to be transmitted; 
retrieve the packets pointed to by me dequeued datagram 

descriptors from the packet buffer; 
access channeLjable to determine the appropriate I/O port 

from which to transmit the packet; 
transfer the packets to the appropriate I/O port for 

transmission to the packets' destination; 
destroy dequeued datagram des criptors; 

} 

Reassemble Received Packet Data 

if a request to receive a specific number of packets for a specified 
channel is received from the streamer process then 
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dequeue one datagram descriptor ftom the head of the 
receive queue associated with the specified channel 
for each packet to bo reassembled; 

retrieve the packets pointed to by the dequeued datagram 
descriptors from the packet buffer; 

Loop while more data in retrieved packet payloads 

{ 

If the offset field of the datagram descriptor Indicates 
that the payload data of the retrieved packet 
is to be placed in an allocated but incomplete 
data unit descriptor then 

insert data of the payload of the retrieved 
packet into the segment pointed 
to by the allocated data imit 
descriptor until the end of 
segment is reached; 

else 
{ 

allocate a data unit des c r i ptor; 

insert data of the payload of the retrieved 

packet into the segment pointed to by 

the allocated data unit descriptor until 

the end of segment is reached; 

} 

if a data wm't descriptor is completed then 
return data unit descriptor to appropriate 
application; 

} 

destroy dequeued datagram descriptors; 

} 

Obtain Data For Transmission 

if data is received for transmission on channel mput_channeLJD 
then 

loop while more received data to segment 



{ 



if the transmission queue for in p " ^*^"? 1 * 1 ^. TP is full 
men 

if replacement attribute of mis channel = ~ 
ncc-replaccable then 

{ 

indicate where writing stopped; 
break; 



dequeue datagram descriptor from bead 
of transmit queue associated 

witn rpput ehamml TO ; 

retrieve packet from packet buffer 

pointed to by the dequeued 

datagram descriptor; 
destroy the dequeued datagram 

descriptor and retrieved packet; 

} 

segment data into a packet; 

store the segmented packet in the packet buffer, 

allocate a datagram descriptor and set pointer to point 

to memory locatioc at which the segmented 

packet is stored in the packet buffer, 
enqueue the allocated datagram descriptor into the 

tail of the transmit queue associated with 

input ch*»ni>H TT> ; 

> 

Receive Packets from I/O Port 

if an VO port has a packet to be received then 
{ 

access charmeL_table to determine the channel of the 

received packet; 
store the received packet in the packet buffer, 
allocate a d a tagr am descriptor for the packet which points 
to mo location in me packet buffer at which the 
received packet was stored; 

the glVy-atad datagram descriptor in to the ft"1 of 
the receive queue associated with the channel of the 
received packet; 



} 
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The operation of the invention is now described with 
reference to FIG. 7. This discussion is divided into the 
following sections to facilitate the understanding of the 
invention: A. Defining Channels, B. Allocating Channels, C 
Application Transfer of Data on Allocated Channels, D. 
Regulating Transmission and Receipt of Data, E. Packet 
Transmission and Receipt from I/O Ports, and F. Commu- 
nication Set Up. 

A. DEFINING CHANNELS 

Initially, a system designer utilizes the formulation pro- 
cess 310 to generate the channel type table 312 such as is 
depicted below: 



15 
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Channel TVne Table 






attribute 1 




channeL_type 


(Access Mode) 


attribute2... 


CTRL (control) 


non-replaceable 




CM (Mntinuous media) 


replaceable 




IM (interactive media) 


replaceable 




RD (reliable data) 


non-replaceable 





25 Once initially defined, the channel type table 312 is not 
altered during normal operation. Illustratively four types of 
channels are defined: CTRL (control) for delivering control 
messages, CM (continuous media) for delivering video, 
audio or other streamed data, IM (interactive media) for 

30 delivering interactive communications, such as telephonic 
audio, teleconference video, teletext, etc., and RD (reliable 
data) for delivering data with a high level of integrity (lower 
incidence of error). Furthermore, fixed attribute values are 
defined for each attribute for each channel type. 

35 Illustratively, the attributes are preselected. An exemplary 
attribute called "access mode 1 ' is shown above as attribute L 
This attribute has two possible attribute values, namely, 
replaceable and non-replaceable. As discussed in greater 
detail below, this attribute controls the ability to accept 

4Q packets for transmission when the transmit queue, e.g., the 
transmit queue 334-1, of the corresponding channel, e.g., the 
channel 1, is full. If the transmit queue 334-1 corresponds to 
a channel with non-replaceable access mode, the packet 
cannot be accepted. 



45 



B. ALLOCATION AND DEALLOCATION OF 
CHANNELS 



When an application desires to communicate, the appli- 
cation first issues a request to allocate one or more commu- 

so nication channels of the predefined channel types to the 
real-time scheduler process 320. Only channels of the pre- 
defined type (in the channel type table 312) may be allo- 
cated. Illustratively, each communication channel is a sim- 
plex communication channel, ix., for communicating in a 

55 single direction (transmitting or receiving but not both). As 
shown, N channels are provide for transmission and M-N 
channels are provided for receipt where N and M are 
integers. For example, suppose the application wishes to 
transmit previously stored (non-interactive) real time audio 

60 and video data. The application may therefore issue a 
request for a CTRL channel and two CM channels. When 
issuing the request, the user or application can specify 
users-definable parameter values for a preselected set of 
parameters. For example, the following is an illustrative 

65 preselected set of parameters: QOS (quality of service), 
(BW) bandwidth, buffers, header information, channel 
direction (transmit or receive). Illustratively, the real-time 
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scheduler process 320 assigns default parameter values for 
those parameters not specified by the application or user. 
However, at least some basic header information must be 
provided by the application. In the case of a transmit 
channel, the application must provide enough header infor- 
mation to construct a packet for transmission and routing to 
a destination host (e.g., the address of the host which is to 
receive the packet). In the case of a receive channel, the 
application must provide enough header information to 
correlate a received packet to the channel to which it 
corresponds. 

In response to receiving requests to allocate channels, the 
real-time scheduler process 320 first determines if there are 
sufficient resources to accommodate the requested channels 
in addition to previously allocated channels. The resources 
include: buffer space (e.g., in the buffers 332, 338), band- 
width on the appropriate communications network, space in 
the allocated channels table 314, etc. If insufficient resources 
are available to satisfy a requested channel of a request, the 
real-time scheduler process 320 may: 

(1) reject the request entirely, 

(2) reject only those channels of the request for which 
insufficient resources are available, or 

(3) negotiate with the application (offer to allocate a 23 
channel with fewer resources, but which can be 
accommodated). 

If there arc sufficient resources to satisfy the request for 
one or more channels, the real-time scheduler process 320 
allocates the necessary resources and causes the formulation 
process 310 to allocate the requested channels with the 
specified and/or default parameter values. In response, the 
formulation process 310 allocates the channels by adding 
table entries to the allocated channel table 314 for the 
requested channels. For example, suppose that before the 
above request for one CTRL channel and two CM channels 
(for the non-interactive audio video communications), the 
allocated channel table 314 possessed the following entries: 



Allocated Channel Table ("initial) 
channel ID parameters chanoeL_type attributes 



1 


QOS = 1, buf = 1, 


CTRL 


DonrepL 


2 


QOS = 1, but =: 2, 
BW= ttkHtteec,... 


RD 


nonrepl. 






3 


QOS = 3, buf. = 3, 


CM 


repL 




BW= 56kbit/8<c^ 




4 


QOS = def^ buf. = 20, 


CM 


rcpL 




BW=1.2Mbii/soc,... 





Suppose the requested channels are CTRL with basic 
header information and receive direction, CM with basic 
header information, 1.55 Mbit/sec, 10 buffers and transmit 
direction and CM with basic header information, 384 kbit/ 
sec, 3 buffers and transmit direction. The formulation pro- 
cess 310 adds three entries to the allocated channel table 314 
as follows: 
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Allocated Channel Table rffobseanenf) 




channel D parameters 


ctuumeLjtype 


attributes 


3 


QOS = 3, buf. = 3, 


CM 


repL 




BW = 56kbh/sec,». 






4 


QOS = def buf. = 20, 


CM 


repL 




BW= 1.2Mbitfcec,... 






5 


QOS = def„ buf. - dcf., 


CTRL 


naniepL 




BW = decree.,... 






6 


QOS = def, buf. = 10, 


CM 


repl. 




BW = 1.55Mbitsec, xmit,.- 






7 


QOS = def, buf. = 3, 


CM 


repl. 




BW = 384kbit/sec, xmit,... 







15 



20 



30 



35 



40 



45 



50 



55 



In addition to allocating the channels, the formulation 
process 310 generates a transmit queue 334 or a receipt 
queue 336 for each channel. Illustratively, the CTRL channel 
5 is a receipt channel and the CM channels 6 and 7 are 
transmit channels. Thus, (he formulation process 310 gen- 
erates a receipt queue, e.g., the queue 336-M, for channel 5, 
a transmit queue, e.g., the transmit queue 334-(N-l) for the 
channel 6 and a transmit queue, e.g., the transmit queue 
334-N, for the channel 7. Illustratively, the formulation 
process 310 allocates a transmission or receipt queue 334 or 
336 of a size which depends on the buffers parameter of the 
corresponding channel. For example, the formulation pro- 
cess may provide each queue 334 or 336 with a number of 
spaces for storing a datagram descriptors equal to the 
number of buffers specified in the buffers parameter. Thus, 
the formulation process 310 allocates a transmit queue 
334-(N-l) (for channel 6) with a capacity to store 10 
datagram descriptors and a transmit queue 334-N" (for chan- 
nel 7) with a capacity to store 3 datagram descriptors, 
likewise, the formulation process 310 allocates a receipt 
queue 336-M (for channel 5) with a capacity to store a 
default number of datagram descriptors. After allocating the 
channels, the formulation process 310 returns the channel_ 
ID to the application for purposes of providing the applica- 
tion a reference for accessing the channel. 

An application can also deallocate channels by issuing an 
appropriate request to the real-time scheduler process 320 
which specifies the channel_ID*s of the channels to be 
deallocated. The real-time scheduler process 320 deallocates 
any resources, such as bandwidth and buffers reserved for 
the channels to be deallocated. The real-time scheduler 
process 320 also causes the formulation process 310 to 
remove the table entries in the allocated channel table 314 
corresponding to the channels to be deallocated. The for- 
mulation process 310 furthermore destroys the receive 
queues 336-(N+l), . . . , or transmit queues 334-1, . . . , 
corresponding to the deallocated channels. 

C. APPLICATION SUBMISSION AND RECEIPT 
OF DATA ON CHANNELS 



Allocated Channel Table ftmbseouenn 
charuieLD parameters 



chameLJype attributes 



QOS = 1, buf. = 1, 
BW«def^ M . 
QOS = 1, buf. = % 
BW= 64kbitfsec,... 



CTRL 



RD 



DoorepL 
nonrepL 



The applications which have information to transmit Issue 
a request to the streamer process to transmit data on a 
specified transmit channel. The request includes a segment 
of data for transmission and the channel ID of the transmis- 
60 sion channel on which the data is to be transmitted. In 
response, the streamer process 330 executes the following 
steps so long as there is remaining data to be transmitted. 
First, the streamer process 330 determines if the transmis- 
sion queue, e.g., the transmission queue 334-1, associated 
65 with the specified transmit channel, e.g. channel 1, is full. If 
not, the streamer process 330 segments the data (or a part 
thereof) into a packet The streamer process 330 then stores 



02/29/2004, EAST Version: 1.4.1 



5,699,361 

17 18 

the packet in the packet buffer 332. (illustratively, the packet Based on this analysis, the real-time scheduler 320 deter- 

bufferis a part of the main memory 116 or disk memory 118 mines on which channels data should be transmitted and 

designated for temporarily storing packets.) In addition, the received and bow much data should be transmitted thereon 

streamer process 330 allocates a datagram descriptor for the or received therefrom. This determination is made based on 

stored packet. In allocating the datagram descriptor, the 5 the attribute and parameter values of each channel For 

streamer process writes appropriate values in each field of instance, CM channels should transmit andreceive data at an 

the datagram descriptor. For example, the streamer process approximately continuous rate (equal to the bandwidth 

330 writes in the pointer field the location of the stored Prefer). If toolMe information is received the appli- 

packet in the pactet buffer 332. The streamer process 330 Mtlon .«»" underflow and a humanly detectable gap will 

also writes in the offsetfield the location, relative to the start , 0 occur in the collocations. If too much informahon is 

of the segment, of the first byte of thepayloadof thepackeL receive^ me appl^abon could overflow and somemforma- 

For example if the first byte segmented into the packet to0 1 n ^ be discarded Generally speaking, most CM chan- 

payload is the 512th byte of the data segment, the streamer nels « a J lttle tempos variance in data rate 

process 330 writes the value 512 in the offset field. This provided that the data rate on average is equal to the 

offset information is also stored in the header of the packet » bandwidth pmita : value. Furthermore, low bandwidth 

The purpose of the offset field is described in greater detail chanB , d * not *» f°^ d MV morc ba ? dwidth ^ 

below in connection with receiving packets. The streamer s P eclficd thar bandwidth parameter values so that 

process 330 enqueues each datagram descriptor into the tall bandwidth wffl be available for the higher band- 

of the transmit queue, e.g., the transmit queue 334-1, asso- dumnd j s - ^ me sd, f duler $™ 

dated with the channel on which the packet is to be 20 ^^^mtoau^m^d^nuto^oatea 

transmitted, eg., the channel 1. The acwal ttansmission of *PP™P™* amount of bandwidth to each channel, 

the packets Is described in greater detail below. After determining on which channels transmission and 

Assume now that the transmit queue 334-1 into which the *f ^ Jf how much J?* 10 transmit 

datagram descriptor is to be placed is full In such acase, the OTrecelve ' •f real-r^scnedmer process 320 issues oneor 

streamer process 330 accesses the allocated channels table * mo f to *• ^f^f^ 330 for transmitting 

314 to determine the access mode attribute of the channel P*^*' » for ^ S<a ? Win8 1 d f segments *T 

(e.g., channel 1). If the packet is to be transmitted on a Pf* 6 *' of ^dfted ^nnek In response to the requests, 

channel (e.g., channel 1) having a replaceable access mode *e streamer process 330 enables the transmission orrecelpt 

attribute value, the datagram descriptor at the head of me of ^ ° n d ^f b °f me 

respective transmU queue of the channel <e.g., the transmis- 30 amoul * niustraUvely, the real-ume schedulerpro- 

sion queue 334-1 of the channel 1) is dequeued. (Jhe packet cess 320 sequentaUy issues a request to transmit or receive 

corresponding to the dequeued datagram descriptor is a number of packets of each designated channel 

retrieved from die packet buffer 332. Then, both the data- separately. 

gram descriptor deleted from the head of the queue 334-1 ^ *» of recel P t ' me streamer process 330 dequeues, 

and its corresponding packet are discarded.) This creates a 35 in a first-in first-out order, datagram descriptors from the 

space at the tail of the queue (eg., the queue 334-1) into head rf me receipt queue 334-(N +1), 334-(N+2), . . . , 

which the datagram descriptor of the newly generatedpacket 334-M associated with the receive channel N+l, N+2, ... , 

to be transmitted is inserted. On the other hand, if the packet M designated in the request issued by the real-time sched- 

is to be transmitted on a channel having a non-replaceable "** P™* 85 32 °" Ulnstratively, the number of datagram 

access mode attribute value, the datagram descriptor for the 40 descriptors dequeued equals the number of packets to be 

newly generated packet is not enqueued. Instead, the received. The streamer process 330 reassembles the data 

streamer process 330 issues a message to the application segments from the payload data in the packets indicated by 

indicating that no more data can be transmitted and indicat- mc dequeued data unit descriptors. In so doing, the streamer 

ing at what point in the data segment acceptance of data P 100 " 5 330 accouats for me possibility mat packets may 

stopped. 45 have been received out of order. Typically, packets trans- 

Whenever data is reassembled from received packets, the mittcd in a such as an Ethernet LAN, arrive in the 

streamer process 330 delivers the reassembled data directly »** sc ^ cnt ^ 10 J^ch transmitted. 

lolfaecQneqKmdl^ However packets transmitted on a WAN such as the 

330 reassembles data from received packets, thVreas- tymcafly arrive tn a different <*^^e order in 

sembled data is stored teir^orarily in the receive buffer 338. *> which fcey were transimttedVTo ensure that data is reas- 

(Like the packet buffer ^Tme receive buffer 338 is part of 5Cmblcd in mc P 0 *** ordcr ^ ^ received packets, the 

the main memory 116 or disk memory 118 which is desig- J~f~ [^^^ uscs *e information stored in 

nated for temporarily storing reassembled data.) The offs * f to ^ P^cment of the 

streamer process 330 allocates a data unit descriptor which reassembled data of each packet. 

points to the location of the reassembled data in the receive 55 reassembled data is then placed in one of the receive 

buffer 338. Therefore, the streamer process 330 need only buffers 338. The streamer process 330 also allocates a data 

return the data unit descriptor for the reassembled data. The unit descriptor for each segment which indicates the location 

reassembly of data from received packets is discussed in of the segment in the receive buffers 338. The streamer 

greater detail below. process 330 transfers the data unit descriptor which points to 

60 the appropriate receive buffer containing the reassembled 

D. RE GULAT ION OF TRANSMISSION AND data segment to the appropriate application. Ulustrarively, 

RECEIPT OF DATA ON CHANNELS the streamer process 330 waits until each data segment is 

The real-time scheduler 320 responds to a timer process completed, i.e., until a requisite amount of data is placed in 

340 which timer process 340 transfers a control message to the data segment, before transferring the data unit descriptor 

the real-time scheduler 320 at regular intervals. In response 65 to the application. 

to the control messages of the timer process, the real-time In the case of transmission, the streamer process 330 

scheduler 320 examines the allocated channels table 314. dequeues, in a first-in first-out order, datagram descriptors 
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from specified transmit queues 334-1, 334-2, . . . , 334-N 
associated with the transmit channels 1, 2, . . . , N on which 
information is to be transmitted. The channels of the trans- 
mit queues from which datagram descriptors were dequeued 
are indicated in the requests received from the real-time 
scheduler process 320. Illustratively, the requests also indi- 
cate the number of packets to be transmitted for each 
transmit channel 1, 2, . . . , N. The streamer process 330 
accesses the allocated channel table 314 to determine the 
appropriate I/O port 122 from which to transmit the packet. 
(Illustratively, this is either stored as a parameter or discer li- 
able from a parameter which specifies the destination of the 
packet). The streamer process 330 then transfers the packets 
indicated by the dequeued datagram descriptors from the 
packet buffer 332 to the appropriate I/O ports 122 for 
delivery to the intended destinations of the packets. The 
streamer process 330 then destroys the dequeued datagram 
descriptors. 

E. TRANSMISSION AND RECEIPT OF 
PACKETS VIA I/O PORTS 

At the lowest level are the I/O ports 122. The I/O ports 
122 receive packets for transmission from the streamer 
process 330 and transmit the packets on the attached com- 
munications network The I/O ports 122 also periodically 
receive packets destined to the host 100. Each received 
packet is transferred to the streamer process 330. The 
streamer process 330, in turn, stores the received packet in 
the packet buffer 332 and determines from which receipt 
channel the packet was received, e.g., the receipt channel 
N+2. To that end, the streamer process 330 accesses the 
allocated channels table 314. (Illustratively, the incoming 
packet specifies unique information, such as the channeLJD 
or a parameter stored for a specified channel, which can be 
used to correlate packets to their respective receive 
channels.) The streamer process 330 then generates a data- 
gram descriptor far the received packet which indicates the 
location of the received packet in the packet buffer 332. The 
streamer process 330 may also extract offset information 
from the received packet header and store this offset infor- 
mation in the offset field of the allocated datagram descrip- 
tor. The streamer process 330 then enqueues the datagram 
descriptor into the tail of the appropriate receipt queue, e.g., 
the receipt queue 334-{N+2) of the appropriate channel N+2. 

F. COMMUNICATIONS SET UP 

As noted above, the communication channels allocated by 
each application executing (by a processor 114) at a host 100 
are all simplex. To enable communication between two 
applications at different hosts 100, each communicating 
application must allocate complementary channels. That is, 
if a first application allocates particular channels with spe- 
cific parameters for transmitting audio and receiving video, 
the other application must allocate channels for receiving 
audio and transmitting video but which otherwise have the 
same parameters (i.e., the same bandwidth, quality of 
service, etc.). Illustratively, two hosts 100 follow a commu- 
nication set up procedure to ensure that allocated channels 
may be used to communicate between applications execut- 
ing at different nodes. Note that two hosts 100 which are 
intended to communicate with each other should have 
identical channel type tables 312. However, it is possible for 
different pairs of communicating hosts to have different 
channel type tables 312 from pair to pair. 

Illustratively, each node initially allocates a special con- 
trol channel for transmission of communication set up 
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control messages and for receipt of communication set up 
control messages. These control channels are advanta- 
geously connection-less; no set up is required to communi- 
cate between hosts via these control channels. Each hosts 

5 utilizes the communication set up control channels for 
setting up communications as follows. Suppose a first appli- 
cation executing (on a processor 114) at a first host 100 
desires to initiate a communication with a second applica- 
tion executing (on a processor 114) at a second host 100 that 

io is connected to the first host 100 via a communications 
medium. The first application issues a request to the real 
time scheduler process 320 (executing on the processor 114 
of the first host 100) to allocate particular channels with 
specified parameters. la response, the real time scheduler 

!5 process 320 d^ermines if sufficient resources are available 
to allocate the requested channels. If so, the real time 
scheduler process 320 executing at the first host also trans- 
mits a communication set up control message packet to the 
second host 100 (as described in the preceding sections). 

2Q The communication set up control message packet indicates 
the type of channels which must be allocated at the second 
host and specifies the parameters of those channels. For 
instance, suppose the first application issues a request to 
allocate a receive video channel of type CM with parameters 

23 bandwidth=1.55 Mbits/sec and quality of service=l and a 
transmit audio channel of type IM with parameters 
bandwidth=384 kbits/sec and quality of serviced. The 
communication set up control message transmitted from the 
real time scheduler process 320 of the first host 100 to the 

30 second host 100 should request allocation of a transmit 
video channel of type CM with bandwidth==1.55 Mbits/sec 
and quality of service=l and a receive audio channel of type 
IM with bandwidth=384 kbits/sec and quality of service=3. 

The communication set up control message received at 

35 the second host 100 is treated as a request to allocate 
channels. This **requesr" issues to the real time scheduler 
process 320 executing (on a processor 114) at the second 
host 100. In response, the real time scheduler process 320 
executing at the second host 100 attempts to allocate the 

40 requested channels in the above described fashion. If suffi- 
cient resources are available at the second host 100, the 
channels are allocated on behalf of the second application 
executing at the second host 100. The real time scheduler 
process 320 at the second host 100 then transmits a com- 

45 mnnication set up control message back to the first host 
indicating that the appropriate complementary communica- 
tion channels were allocated at the second host 100. This 
returned control message is received at the real time sched- 
uler process 320 of the first host 100. In response, the real 

50 time scheduler process at the first host 100 completes the 
channel allocation for using the allocated channels (by 
issuing to the formulation process 310 the appropriate 
requests to allocate channels). 

If insufficient resources are available at the second host 

55 100, the real time scheduler process 320 executing at the 
second host 100 may (1) reject the request outright, (2) reject 
the request in part as to those channels for which insufficient 
resources are available and accept the remainder of the 
request, or (3) attempt to negotiate by offering to allocate 

60 channels requiring fewer resources but which can be accom- 
modated at the second host 100. The real time scheduler 
process 320 executing at the second host 100 illustratively 
transmits a communication set up control message indicat- 
ing one of these three actions to the first host 100 via the 

65 communication set up control channel The control message 
is received by the real time scheduler process 320 at the first 
host 100. In response, the real time scheduler process 320 at 
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the first host may also: (1) reject the request issued by the 
first application outright, (2) reject the request in part as to 
those channels for which the second host indicated that there 
are insufficient resources, or (3) attempt to negotiate with the 
first application by offering to allocate channels requiring 
fewer resources, etc. In the event that the real-time scheduler 
320 at the first host 100 rejects, in whole or in part, the 
request issued by the first application process (in response to 
a rejection/negotiation message received from the second 
host), the real-time scheduler process 320 deallocates any 
resources for those channels which are rejected (by the first 
host). 

Thus, using the above communication set up procedure, 
each application can simply and efficiently initiate a com- 
munication with applications executing at other hosts. As 
noted above, the initiating application need only issue a 
request to allocate channels. Once allocated, the communi- 
cation channels are available far enabling communication 
between the initiating application and another application at 
a remote host 

Note that the real-time scheduler 320 and streamer pro- 
cesses 330 provide for preemptive communication. That is, 
the streamer process 330 transmits or receives information 
for specific selected channels. The specific channels are 
selected by the real-time scheduler process 320 depending 
on the user-definable parameters and fixed attributes of all of 
the allocated channels in the allocated channels table 314. 

Note also that the two step formulation process 310 
enables a system designer to predefine certain channels 
types but allows the application to allocate channels of these 
types with user-definable parameters. Thus, the application 
is not burdened with low level details of defining channel 
types with attributes that will not vary from channel to 
channel of the same type. On the other hand, the application 
has the flexibility to allocate channels of the predefined 
types with varying parameters. This facilitates communica- 
tions of the multimedia type. Enough criteria of the channels 
is predefined to reduce the complexity of providing multi- 
media communication, yet enough flexibility in allocating 
channels is provided to tailor the multimedia communication 
to meet specific needs. 

Note also that conventional hosts 14 (FIG. 1) and hosts 
100 adapted according to the present invention may be 
connected to the same communications medium, Thus, there 
is no requirement to adapt or disconnect each host already 
connected to an existing network. 

In short, a communication system and process are dis- 
closed. The communication system and process provide a 
two-step formulation process which provide a predefined 
and simple procedure for creating communication channels 
which may be flexibly adapted to specific communications. 
The communication method and system according to the 
invention provide for single leveled queuing and for select- 
ing preemptive and non-preemptive transmission queuing. 

Finally, the above discussion is intended to be merely 
illustrative of the invention. Numerous alternative embodi- 
ments may be devised by those having ordinary skill in the 
art without departing from the spirit and scope of the 
following claims. 

The invention claimed is: 

1. A process for communicating in a communications 
network comprising: 
initially defining one cr more channel types and different 

fixed attributes associated with each of said channel 

types, 

dynamically allocating channels, of said channel types 
defined in said step of defining, as needed by applica- 
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tions programs based on specified user-definable 
parameters of each allocated channel, 
transmitting a bit stream including packets on said allo- 
cated channels on a schedule which depends on said 
5 parameters and said fixed attributes associated with 
each of said . allocated channels. 

2. The process of claim 1 wherein said step of transmitting 
further comprises the steps of: 

dividing segments of information into packets to be 

transmitted on each allocated channel, 
enqueuing descriptors corresponding to said packets into 

queues corresponding to channels of said packets, 
selecting from which of said channels to transmit packets 
15 depending on said user-definable parameters and said 
fixed attributes of each allocated channel. 

3. The method of claim 2 further comprising the step of: 
submitting said information for transmission prior to said 

step of segmenting, 
20 wherein only single level queuing is used to sequence said 
information for transmission between said step of sub- 
mitting and said step of transmitting. 

4. The process of claim 2 wherein said step of enqueuing 
further comprises the step of: 

25 in the event one of said queues is full, discarding a 
descriptor already in said queue and a packet corre- 
sponding thereto, depending on an access mode 
attribute of said respective channel. 

5. The process of claim 1 further comprising: 
receiving packets from one or more VO ports correspond- 
ing to communications on said allocated channels, 

enqueuing a descriptor corresponding to each of said 
received packets in a queue corresponding to said 
35 allocated channel of said received packet, 

in response to said user-definable parameters of each 
allocated channel, selecting particular allocated chan- 
nels from which to receive data, and 
reassembling said received packets corresponding to 
descriptors in queues of said selected allocated chan- 
nels into data segments. 

6. A process for communicating in a communications 
network comprising the steps of: 

initially defining one or more channel types and different 
fixed attributes associated with each of said channel 
types, 

dynamically allocating channels, of said channel types 
defined in said step of defining, as needed by applica- 
tions programs based on specified user-definable 
parameters of each allocated channel, 
receiving a bitstream organized into packets including 
packets received from one or more of said allocated 
channels, and 

ss reassembling said received packets into data originally 
transmitted on said one or more allocated channels 
according to a schedule which depends on said user- 
definable parameters and said fixed attributes associ- 
ated with each of said allocated channels. 

£0 7. A host in a communicati on system comprising: 

a processor for initially defining one or more channel 
types and different fixed attributes associated with each 
of said channel types, dynamically allocating channels, 
of said defined channel types, as needed by applications 

65 programs executing on said processor, based on speci- 
fied user-definable parameters of each allocated 
channel, and scheduling packets for transmission on 
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said allocated channels on a schedule which depends on 
said parameters and said fixed attributes associated 
with each of said allocated channels, and 
at least one I/O port far transmitting a bitstream including 
said packets as scheduled by said processor. 5 

8. The host of claim 7 further comprising: 

a memory for storing a channel type table containing an 
entry for each of said one or more channel types defined 
by said processor and an allocated channel table con- 
taining an entry for each of said channels allocated by 10 
said processor. 

9. The host of claim 8 further comprising: 

a bus connecting said processor, said memory and said at 
least one I/O port and far transferring data between said 15 
processor, memory and said VO port including packets. 

10. A communications network comprising: 

a communications medium for carrying a bitstream orga- 
nized into packets, and 
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a plurality of hosts connected to said communications 

medium, each of said hosts comprising: 

a processor for initially defining one or more channel 
types and different fixed attributes associated with 
each of said channel types, dynamically allocating 
channels, of said denned channel types, as needed by 
applications programs executing on said processor, 
based on specified user-definable parameters of each 
allocated channel, and scheduling packets for trans- 
mission on said allocated channels on a schedule 
which depends on said parameters and said fixed 
attributes associated with each of said allocated 
channels, and 

at least one I/O port for transmitting a bitstream includ- 
ing said packets as scheduled by said processor on 
said communications medium to another one of said 
hosts. 

* * * * * 
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